1. Field of the Invention
The invention relates to the field of communication. More specifically, the invention relates to providing point-to-multipoint label switch paths (LSPs) in a Multi-Protocol Label Switching (MPLS) network.
2. Background of the Invention
The multi-protocol label switching (MPLS) protocol may be categorized as a network layer protocol of the Open Standards Institute (OSI) reference model. MPLS provides a method for generically tunneling data through networks with label switched paths (LSPs). MPLS forwards data using labels that are attached to each data packet. These labels are distributed between the nodes that comprise the network.
Extended Resource Reservation Protocol referred to as RSVP Traffic Engineering (RSVP-TE) may be used as a signaling protocol to establish LSPs in the MPLS network. Generic RSVP uses a message exchange to reserve resources across a network for IP flows. RSVP-TE enhances generic RSVP so that it can be used to distribute MPLS labels and to establish traffic engineered (TE) LSPs that can be automatically routed away from network failures, congestion and bottlenecks and satisfy various other policies related to network performance optimization. TE LSPs typically carry a set of flows aggregated by their service class.
While RSVP-TE defines a mechanism for setting up point-to-point (P2P) TE LSPs, it does not provide a mechanism for building point-to-multipoint (P2MP) TE LSPs. A P2MP LSP is a label switched path that has one unique ingress label switching router (LSR) and multiple egress LSRs.
P2MP technology becomes increasingly important with the growing popularity of real-time applications such as content delivery services and video conferences that require P2MP real-time transmission capability with much more bandwidth and stricter quality of service (QoS) than non-real-time applications.
Seisho Yasukawa and Allan Kullberg have recently proposed protocol extensions to RSVP-TE for P2MP MPLS in the publication entitled “Extended RSVP-TE for Point-to-Multipoint LSP Tunnels.” The proposed protocol extensions provide for signaling the P2MP LSP using a tree explicit route object that describes the P2MP tree topology. The P2MP tree is calculated and signaled as the tree explicit route object all LSRs participating in a session. If a new receiver is added to the session or an existing receiver is removed from the session, the whole tree is recomputed, an old tree is deleted, and the recomputed tree is signaled to the participating LSRs.
The approach of Yasukawa, et al., has a number of limitations. Specifically, in a large network, receivers are typically added to the session and removed from the session rather frequently. Each time such a change happens, the P2MP tree has to be recomputed and re-distributed to the participating nodes, thus creating a significant overhead.
In addition, if the use of a new P2MP tree begins before all copies of an old P2MP are deleted, a race condition may occur in the MPLS network. RSVP-TE does not provide support for resolving a race condition caused by the existence of the two trees in the network. Hence, an additional mechanism is needed to address such race conditions.
Further, this approach significantly increases the size of messages exchanged by the LSRs in the MPLS network because the P2MP tree has to be sent to each LSR along the P2MP LSP.